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In spite of the increasing dominance of 
high-level languages and integrated 
development environments, the optimi- 
zation of assembly language code is still 
a fashionable subject fqr on-line debates. 
Thus the Programming Forum on PC 
MagNet has been the venue for many 
"coding challenges": one member de- 
scribes a small but interesting program- 
ming problem, then sits back to see who 
can solve it in the fewest number of bytes. 
Similarly, the assembler/cpu8088 confer- 
ence on BIX has been the site of many 
grave deUberations on obscure assembly 
language optimization issues. 

Grass-roots interest notwithstanding, 
the literature on Intel 80jc86 assembly 
language optimi/ation is surprisingly sparse. 
While preparing a talk on this subject for 
the Software Development Conference a 

uple of years ago, I searched the back 
issues of the major programming maga- 
zines and found only a handful of ar- 
ticles. The literature on code optimiza- 
tion for high-level language compilers, 
on the other hand, is quite extensive, and 
many of the concepts developed in this 
literature are useful in assembly language 
coding as well. I've included a bibUogra- 
phy for those of you who wish to explore 
this subject fiirther (see the sidebar "Further 
Reading"). In the meantime, let's survey 
some of the more common optimization 
techniques and then turn to the larger 
question of when and where to optimize. 

OPTIMIZING FOR SPEED 

Wton ypu decide that a program isn't 
running fast enough, the first thing to do 
is to make sure that you are using the best 
algorithms and data representations for 
the job. Switching from an inappropriate 
or primitive algorithm to one that's more 
fitting or clever may well speed up your 
program by an order of magnitude or 
more, so taking the time to peruse Knuth 
or Sedgewick for an algorithm you wouldn't 
be likely to think of on your own is time 
/ell invested. Similarly, changing from 
an "obvious" but simple data structiue 
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To help your assembly 
language programs 
deliver maximum 
performance, sometimes 
you'll want to optimize for 
size, sometimes for 
speed, and sometimes 
you're better off leaving 
well enough alone. 



(such as a linked Ust) to a more sophisti- 
cated structure (such as a B-tree) may 
yield results far out of proportion to the 
programming effort involved. 

Once you're satisfied that you're us- 
ing the best algorithms and data struc- 
tures, the next thing to lock at is the program's 
use of mass storage. Even the fastest disk 
devices used on personal computers are 
abominably slow compared with the 
computing horsepower of an 80386 or 
80486, so you'll want to minimize or 
eliminate disk I/O whenever possible. 
Become familiar with all the tyj)es of 
memory available to a DOS program — 
extended memcMy, expanded memray, upper 
memory blocks, and the high memory 
area — and fully exploit this memory to 
keep your program's data in RAM where 
you can get at it quickly. You may even 
want to look into data compression tech- 
niques, because it will almost always be 
faster to squeeze data and unsqueeze it 
again than tp le^t} ft two at morp times 
from disk. 

Another important area to address is 



reducing your program's cak^ulaticHi burdm. 
The compiler writers have fancy 
terms — common subexpression elimina- 
tion, constant folding, constant propa- 
gation — ^for variations on the basic rule 
that your program should never calculate 
the same value twice at runtime; instead, 
it should calculate the value once, and 
save it for reuse. An even better solution 
is to move calculations from runtime to 
assembly time whenever die limited mathe- 
matical abilities of MASM (or TASM or 
OPT ASM) allow. Along the same lines, 
you may be able to enhance a program's 
performance drastically by converting 
calculations to table lookups, and making 
use of tables that are generated and stored 
on-disk ahead of time by a separate pro- 
gram. 

Once you've done whatever can be 
done at these more abstract levels, you're 
pretty much reduced to classic code hacking 
and cycle shaving to improve your pro- 
gram's performance — ^particularly if your 
program is heavily display-oriented and 
performs its own memory-mapped video 
output. Some of the more common op- 
timizations in this category are: 

■ Substitution of fast special-case sequaKes 
of instructions fot nwte generalized, complex 
instructions, such as replacing a hardware 
multiply by a power of two with a shift or 
series of shift instructions (strength re- 
duction). 

■ Reducing the overhead of jumps and 
calls by converting subroutines to macros 
and assembling them in-line; changing 
the sense of conditional jumps so that the 
jumps are taken on the less common 
condition; moving common cases to the 
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FURTHER READING 



by Ray Duncan 

The following are selected readings on 
code optimization for assembly lan- 
suage programmers. 




,ompilers: Principles, Techniques, 
and Tools, chapter 10, by Alfred Aho, 
Ravi Sethi, and Jeffrey Ullman, Ad- 
dison-Wesley Publishing Co., Read- 
ing, Mass., 1986. 

■ Crafting a Compiler, chapters 15 
and 16, by Charles Fischer and Rich- 
aid LeBlanc, Benjamin/Cummings Pub- 
lishing Co. Inc., Menlo Park, Calif., 
1988. 

■ Programming Pearls, chapters 3, 
5, 8, and 9, by Jon Bentley, Addison- 
Wesley Publishing Co., Reading, Mass., 
1986. 

■ Writing Efficient Programs, by Jon 
Bentley, Prentice Hall Publishing Co., 
Englewood Chffs, N.J., 1982. 

■ The Zen of Assembly Language, by 
Michael Abrash, Scott Foresman & 
Co., Glenview, IIL, 1990. 



ARTICLES: 

■ "Assembly Language Tricks of the 

Trade." by Tim Paterson, Dr. Dobh's 
Journal. March 1990, page 30. 

■ "Loop Unrolling," by Mark 
Barrenechea, Programmer' s Journal, 
July/August 1991. page 66. 

■ ■"More Optimizing for Speed," by 
Michael Abrash, Programmer s Jour- 
nal, July/August 1986, page 36. 

■ ' 'Optimania,' ' by Mark Barrmediea, 
Programmer s Journal, Januaiy^eb- 
ruary 1991, page 72. 

■ ' 'Optimization Strategies," by Gary 
Sarff, Computer Language, December 
1985. page 27. 

■ ' Optimizing C with Compiler-Gen- 
erated Assembly," by John Ross, Com- 
puter Language, November 1988, page 
59. 

■ "OptimizingCompilers,"byMark 
Roberts, BYTE. October 1987, page 
165. 

■ "Optimizing Compilers for C," by 
Richard Relph, Dr. Dobb's Journal, 
August 1987, page 42. 



■ "Optimizing for Speed," by Mi- 
chael Hoyt, Programmer's Journal, 
March/April 1986, page 32. 

■ " "Optimizing Integer Multiplications 
by Constant Multipliers," by Robert 
Grappel, Dr. Dobb's Journal, March 
1987, page 34. 

■ "Peak Performance." by Mark 
Barrenechea, Programmer' s Journal, 
November/December 1990, page 64. 

■ "Pushing the Envelope." column 
by Michael Abrash in PC Techniques, 
u "Roll Your Own Languages with 
Mini-interpreters, ■ by Michael Abrash 
and Dan Illowsky,D;-. Dobb's Journal, 
September 1989, page 52. 

■ "Secrets of Optimization," by 
ter Bright, Micro Cornucopia, J. 
February 1989, page 26. 

■ "8088 Assembly-Language Program- 
ming Techniques." by Tom Disque, 
Dr. Dobh's Journal. July 1987, page 
24. 

■ "80x86 Optimization," by Michael 
Abrash, Dr. Dobb's Journal, March 
1991, page 16. 



fipont of multiway jumps; converting calls 
followed immediately by returns into jumps 
("tail merging" and "tail recursion op- 
timization"), and so on. 

■ Various loop optimizations including 
moving the calculations of invariant val- 
ues outside of loops, simplifying calcula- 
tions inside of loops, unrolling loops, and 
consolidating separate loops that are exe- 
cuted the same number of times into a 
single loop ("loop jamming"). 

■ Taking maximum advantage of the 
available registers by keeping working 
values in registers whenever possible to 
minimize memory accesses, packing multi- 
ple values or flags into registers, and elimi- 
nating unnecessary stack pushes and pops 
(especially at subroutine entries and ex- 
its). 

■ Exploiting CPU-specific instructions 
such as the push immediate value instruc- 
tion that is available on 80286 or later 
CPUs, or the doubleword string instruc- 
tions, 32-bit by 32-bit multiply, 64-bit by 
32-bit divide, and multiply by immediate 
value instructions that are available on 

'1^9 PC w&a3m NDVEMnaiEn 26. t99i 



80386 and 80486 CPUs. Of course, your 
program must first determine which CPU 
it is running on! The routine shown in 
Figure 1 can help in this regard: It returns 
a code indicating CPU type. 

On 80286 and later CPUs, you may 
also be able to improve execution speed 
by a few percent by aligning data items 
and the targets of jump instructions on 
appropriate boundaries. The 8086 and 80286 
are 16-bit CPUs and like to see things 
aligned on 16-bit (word) boundaries; the 
80386 prefers 32-bit (doubleword) align- 
ment; and the 80486 performs best with 
paragraph (16-byte) aUgnment because of 
the design of its internal cache. 

If all else fails and you're writing a 
specialized application rather than a mass- 
market software package, you can usu- 
ally trump your performance problems 
with hardware. At today's mail-order prices, 
the cost of replacing the machine your 
application runs on with a new, much 
faster machine may be considerably less 
than the cost of the time required for you 
to painstddngly redesign, oi^imize, and 



re-debug the application. Unfortunately, 
flie undiscriminating embrace of this strat- 
egy by vendors such as Microsoft and 
Lotus has brought us bloated monstrosi- 
ties such as Windows 3.0, Programmer s 
Workbench, and Lotus 1-2-3IG, but that's 
a subject for another day. 

OPTIMIZING FOR SIZE 
If your program is too big to run (rather 
than too slow), you need to fall back on 
optimization strategies that are in most 
ways the exact inverse of the tricks you 
use for speed. First examine your pro- 
gram carefully to determine whether the 
primary problem is code size or data size. 

If your data is too big, sophisticated 
data structures may help, but the elimina- 
tion of fast but sparse arrays or tables in 
favor of more compact stractures such as 
linked lists and the packing of data using 
bit fields will probably yield more short- 
term benefits. Brute force compression 
and decompression of tables or structure' 
as they are needed is not usually ver^ 
useful, because it's often necessary to 
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COMPLETE LISTING 



.486 



CPUTYPB — Check CPU Type 
55,132 



CPOTYPE.ASM - Returns Intel CPU type. Adapted froai 

source code dUtrlbutad to isve by Intel corp. 



; Call with I 
; Returns I 



. CPU type 
0086H - 80Q6 or 8088 
0286H - 80286 

0386B = 80386SX or 8I386DX 
04868 - 80486SX or 80486DX 



t DMtC«y«i i^per 16-bits of SAX and BCX on 386/486 
TBXT ■egmcDt word aselC p^lle 'codk' 



ossune 


e»t_TBXS 




public 


opntype 




oputype proc 


near 




puBhf 




t 


puah 


bx 


f 


push 


cx 




pusbf 




; 


pop 


ax 


F 


and 


ax,0fffh 




push 


ax 




popf 






pushf 






pop 


ax 


; 


and 


ax, 0£000h 


; 


crop 


ax,0£00eh 


; 


jne 




t 


■cnr 




1 


jmp 


cpux 


t 



■ave copy of flags and 
otfaer affected registers 



now try to clear bits 13-15 
of CPtJ flags 



set nodlfied CPU flags 



If bits 12-15 are still 
set, this is 8086/88 
jumpf not 8086/88 
set AX - 86/88 CPO type 
and exit 



cptili 



cpu3t 
cpuxt 



cputype endp 
TSXT ends 



or 


BX,0f000h 


push 


ax 


popf 




pushf 




pop 


ax 


and 


ax, 0f 000h 


jnz 


cpu2 


nov 


ax, 286h 


jmp 


cpux 


mov 


bx, sp 


and 


sp,not 3 


pushf d 




pop 


sax 


nov 


ecx,aax 


xor 


eax,48000h 


push 


eax 


popfd 




puahfd 




pop 


sax 


mov 


■P^bx 


xor 


eaxrvox 


}nz 


0pii3 


DOT 


ax,0386h 




cpux 


mov 




pop 


ox 


pop 


bx 


popf 




ret 





; must b« 286 or later, 

; now try to set bits 12-15 

( of CPU flaga 

; if bits 12-15 can't be 

; set, this iB a 286 

; jump, not BB286 

; set AX * 266 CPU type 

; and exit 

J 386 or later, save SP 

J avoid stack allgiment fault 

t 9et value of SFLAQS 

I save eopy of EFLaos 
I flip AC bit in STLHes 
t try and force SFLAOS 

I get bask SRMS value 

; restore old staok pointer 
! ean AC bit be ohatt$ed? 
I no, jnmp, not a 38£ 
I set AX = 386 CPD type 
} and exit 

r set AX - 486 CPU type 

t restore regiaters 

; raatore original flags 
I return with AX - epu type 



Figure 1: When a program is running on an 80286, 80386, or 80486 CPU, there are many CPU-specific instructions that can be exploited to 
improve performance. First, however, thie program must be abie to determine the CPU type so it can adapt itself accordingiy. This routine, 
l lrom code distributed by Intel, returns a code Indicating whether the host CPU is an 8088, 8086, 80286, 80386, or 80486. 



%cicxnpress all the data just to get at one 
;m, and the compression/decompression 
routines themselves occupy considerable 
memory. 

Large lookup tables and arrays may be 
built in a disk file and read into memory 
in small chunks when needed, but this 
can have a crushing effect on throughput 
if the data is randomly accessed. Lookup 
tables can often be completely eliminated 
in favor of recomputing values as they're 
needed. You must also search for and 
remove constants and variables that are 
never actu£dly used by the program be- 
cause they were superseded by other 
constants and variables during develop- 
ment and debugging. In any event, I'll 
stress again how important it is for you to 
learn how to access all the types of memory 
that may be available on a PC, and make 
your program flexible enough to use any 
and all of them. 

Optimizing a program's code for size 
is quite a different ballgame than opti- 
mizing it for speed. First you must in- 
spect every line of source code and elimi- 
nate all statements or procedures that are 
never executed or can't be reached from 
"«iy point in the main line of execution 
dead code). If you've got a large appli- 
miion that has gone through a.prolonged 



develgpnent cycle involving several pro- 
grammers, you may be quite surprised at 

the number of lines you can excise. Sec- 
ond, analyze the program again and con- 



Optimizing a program's 
code for size is quite a 
different ballgame than 
optimizing it for speed. 



solidate all identical or functionally simi- 
lar code sequences into subroutines that 
can be called from any point in the pro- 
gram. The more general you can make 
the subroutines, the more Hkely it is that 
their code can be reused. When carried to 
an extreme, this approach leads to a highly 
modular and compact program that con- 
sists mostly of calls. 

At this point, if there still isn't enough 
metaoiy to go aroimd, your efforts can 
diverge in several different directions. You 
can decompose your program into rela- 
tively independent nipdiiles tl^ft can be 



read into memory separately as overlays. 
You can encode your program's func- 
tionality in tables that "drive" its execu- 
tion. You can resort to threaded-code or 
pseudo-code techniques that represent your 
program's logic in considerably less memory 
at some cost in performance. Or you can 
really pull out all the technological stops 
and implement a custom interpreter or 
compiler for a "little language" that in 
turn serves as the virtual machine for 
your application. QuickBASIC, Excel, and 
BRIEF are everyday examples of the 
threaded-code, pseudo-code, and little- 
language strategies, respectively. 

Finally, if you're writing a special- 
purpose application, you may be able (again) 
to simply trump your memory problems 
with hardware or software. Among the 
many possibilities are: upgrading to DOS 
5.0 or OS/2 2.0 to make more memory 
available below 640K, plugging in yet 
another EMS board, switching to a 80386 
or 80486 machine that will support more 
extended memory than your 8086 or 80286 
machine, and/or porting your program to 
run on a DOS extender. 

WHEN TO OPTIMIZE, WHEN TO PUNT 

Code optimization in any language al- 
ways lequiies tradeoJlfs, saqh as: 
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■ trading speed for memory; 

■ trading code maintainability and reada- 
bility for code performance; 

■ trading development time for execu- 
tion time. 

These tradeoffs seem straightforward, 
but more often they aren't as simple as 
they first appear. The following two in- 
structions, either of which can be used to 
transfer a value from register DX into 
AX (with different side effects, of course) 
provide a classic example: 

XCHG AX, DX 
MOV AX,DX 

On an Intel 8088, the MOV instruction is 
2 bytes and requires 2 CPU clock cycles, 
while the XCHG instruction is 1 byte but 
requires 3 CPU clocks. So far, a clear-cut 
tradeoff of speed for memory. But the 
actual performance of the instructions is 
highly dependent on context, the size of 
the CPU's prefetch queue, the size and 
characteristics of system caches, and so 
on, while even the number of clock cycles 
required to execute the instructions var- 
ies from one model of Intel CPU to another. 
As it turns out, it's nearly impossible to 
predict the performance of a nontrivial 
sequence of instructions on an Intel pro- 
cessor, especially on the later CPUs such 
as the 80386 and 80486, which make 
more extensive use of pipelining; you 
simply have to benchmark the various 
possibilities in vivo and see how they 
perform. 

Similarly, the tradeoffs of development 
time for execution time and code main- 
tainability for performance are seldom as 
well ordered as we'd like, and the long- 
term impact of wrong decisions can be 
enormous. By far the most important thing 
to understand about optimization is when 
to do it and when to leave well enough 
alone; as Donald Knuth said, "Premature 
optimization is the root of much program- 
ming evil." Before you can even think 
about tuning up your program, make sure 
it is logically correct and complete, that 
you're using the right algorithm for the 
job, and that you've written the cleanest, 
most straightforward, most structured code 
you possibly can. 

If your program meets these criteria, 
its size and performance will be fine most 



of the time, without any further attention. 
Merely by using assembly language you're 
already getting a two- or threefold speed 
and size advantage over the fellow using 
a high-level language. And many of the 
characteristics that make a program easy 
to read and maintain will also tend to 
make it fast — such as the avoidance of 
spaghetti code with many unnecessary 
jumps and calls (these have a severe penalty 
on the Intel 80x86 architectiue because 
they dump the instruction prefetch queue) 
and the use of simple straightforward 
machine instructions rather than complex 
instructions. 

Nevertheless, the user's perception of 
your program's performance should be 
your overriding concem. As Michael Abrash 
observed, "Any optimization that is per- 
ceptible to the user is an optimization 



Many of the 
characteristics that 
make a program easy 
to read and maintain 
will also tend to 
make It fast. 



worth doing." Conversely, if your pro- 
gram gets the word-of-mouth reputation 
among users of being pudgy and pokey, 
it's very likely to remain unappreciated: 
As an example, consider the fate of 
ToolBook. Consequently, your program 
should appear to be instantly responsive, 
even when it's occupied with time-con- 
suming calculations or disk operations. It 
should keep the screen alive with prog- 
ress indicators such as dials or thermome- 
ters, and allow the user to intermpt lengthy 
operations safely at any time if he changes 
his mind and decides to do something 
else. 

If you do have to resort to the code- 
hacking and cycle-shaving tricks we 
mentioned earlier, avoid the misdirection 
of your time and energy. Bear in mind the 
natural hierarchy of time scales^ — ^ttgister/ 
register operations, memory operations, 
disk operations, and user interactions — each 
of which is an order of magnitude (or 
more) slower than its predecessor. For 



example, don't waste effort trying to save 
a few machine cycles in a routine if your 
program's speed is limited by its acces« 
to disk files; try to identify ways to i 
duce disk I/O instead. It's vital to employ 
profiling tools to identify the hot spots in 
your program and concentrate your atten- 
tion in those areas. And after you make 
each presumptive optimization, time the 
results carefully and test, test, test. 

In his superb book Writing Efficient 
Programs (Prentice Hall, 1982), Jon Bentley 
relates a horror story from Bell Labs that 
we should all take to heart: 

" Victor 'Vyssotsky enhanced a FOR- 
TRAN compiler in the early 1960's under 
the design constraint that compilation time 
could not be noticeably slower. A par- 
ticular routine was executed rarely (he 
estimated during design that it would be 
called in about one percent of compila- 
tions, and just once in each of those) but 
was very slow, so Vyssotsky spent a week 
squeezing every last cycle out of the routine. 
The modified compiler was fast enough. 
After two years of extensive use the compiler 
reported an internal error during compi- 
lation of a program. When Vyssotsky 
inspected the code he found that the error 
occurred in the prologue of the 'critical' 
routine, and that the routine had containe'^ 
this bug for its entire production life.' 

Vyssotsky made three important er- 
rors: He failed to profile the program 
before he optimized it, so he wasted time 
optimizing a routine that had no impact 
on performance; he failed to implement 
the optimized routine correctly; and he 
failed to test the optimized routine to see 
if it worked according to specification. 

Now it's not my intent to pick on Mr. 
Vyssotsky; I've made plenty of far worse 
blunders in my day, though — since I don't 
work at Bell Labs — ^these blunders fortu- 
nately don't get immortalized in Jon 
Bentley's books. But Vyssotsky's expe- 
rience is a good example of how time and 
energy can be wasted in the holy cause of 
optimization, and how a failure to me- 
thodically cover all the bases of profiling 
and validation during optimization will 
usually come home to roost sooner or 
later. 

THE IN-BOX 

Please send your questions, comments, 
and suggestions to me at any of tile fol- 
lowing electronic mail addresses: 
PC MagNet; 72241,52 
MCI Mail: rduncan 

BIX: rduncan ■ 
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